Private Line Emulation over Packet Switched Networks
draft-ietf-pals-ple-15

[Ballot comment]
Thank you for the work on this document and for addressing my previous DISCUSS. Good to go for me now (after IESG approval of downref to RFC3985).

[Ballot comment]
Thank you to Joel Halpern for the GENART review.

Thank you for the detailed and thorough answers to my questions, and addressing my DISCUSS and COMMENT feedback.

[Ballot discuss]
Thanks for working on this specification. Thanks to Tommy Pauly for the TSVART review.

I have one discuss point -

# I didn't find the rational to use RTP header in this protocol. If we are only interestes in timestamp, SSRC and PT (not sure why we need it), and setting rest of bits to zeros then why can't we incorporate timestamp, SSRC in the PLE control word? I would like to see a description on the rationale on the use RTP here and proper description of the RTP endpoint behaviour. To me it is important, as RTP has a particular use and I am not sure if these simulated packets will never reach to a proper RTP endpoint. I think we can improve this specification by explicitly saying best practices for the isolation of the PSN is a MUST, if RTP header is used.

[Ballot comment]

Apart from my discuss point - I had hard time to understand the following section

  The RTP header is purely a formal reuse and RTP mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure Realtime Transport Protocol (SRTP), etc., are not applicable to PLE VPWS.

Specially, what does "purely a formal reuse" mean? My "formal" reuse will mean a proper RTP endpoint with RTCP.

Also please explain the need ofr PT in PLE header.

[Ballot discuss]
Normative language is specified in the document which appears to come from informative references.

— Section 4.2.1,
  When the CE-bound IWF is in PLOS state or when PLE packets are
  received with the L-bit being set, the CE-bound NSP function MAY
  disable its transmitter as no appropriate maintenance signal was
  defined for 1000BASE-X by IEEE.

[IEEE802.3] needs to be a normative reference.

— Section 4.2.2

  The CE-bound NSP function MUST perform

  *  PCS code sync

  *  descrambling

Where are the details of this mandatory behavior specified? Is it [IEEE802.3]? If so, then please cite it normatively. Is it possible to provide section numbers?

— Section 4.2.3

  To gain access to the scrambled 64B/66B code stream the PSN-bound NSP
  further MUST perform …

  The CE-bound NSP function MUST perform …

Same comments as noted above for Section 4.2.2.

— Section 2.2.4
  To gain access to the 64B/66B code stream the PSN-bound NSP further
  MUST perform
…
Further the PSN-bound NSP MUST perform rate compensation and
  scrambling before the PSN-bound IWF is mapping the same into the
  basic PLE payload.
…
  The CE-bound NSP function MUST perform
…
  When sending the bit stream to the CE, the CE-bound NSP function MUST
  also perform

— Section 4.3. Various conformance to [G.707] and  [GR253]  is stated but neither are normative references.

— Section 4.4.* Various statements of the form ‘…  MUST perform‘ are made in these subsections.  However, as in Sections 4.2.*, the FC references are not normative. Can the referenced behavior please be specified more clearly?

— Section 7.2.2

  The recovered clock MUST comply with the jitter and wander
  requirements applicable to the type of attachment circuit, specified
  in:

  *  [G.825] and [G.823] for SDH

  *  [GR253] for SONET

  *  [G.8261] for synchronous Ethernet

  *  [G.8251] for OTN

Given the mandatory conformance guidance in the quote above,  all of the references made in the quote need to be normative.

[Ballot comment]
Thank you to Joel Halpern for the GENART review.


** Section 4.5

The PSN-bound NSP function MUST terminate the FEC and replace the
  OTUk overhead in row 1 columns 8-14 with all-0s fixed stuff which
  results in a extended ODUk frame as illustrated in Figure 3.

What is ‘all 0s fixed stuff’?

** Section 7.2

  While the PLOS defect is declared the CE-bound NSP function SHOULD
  inject the appropriate native downstream fault indication signal.
  Also the PSN-bound IWF SHOULD set the R bit in the PLE control word
  of every packet transmitted.

…

  Whenever the R bit is set in the PLE control word of a received PLE
  packet the PLE performance monitoring statistics SHOULD get updated.

In what cases would the behavior described above not be followed? Why are these a SHOULD and not a MUST?

** Section 7.4

… and SHOULD be provided by a YANG model.  The YANG model
  specification is out of scope for this document.

Why is this sections prescribing normative behavior for something that is out of scope?

** Section 9

    Control
  plane mechanisms for signaling the expected SSRC value are described
  in [I-D.draft-schmutzer-bess-bitstream-vpws-signalling] and
  [I-D.draft-schmutzer-pals-ple-signaling].

Are the signaling mechanisms described in these drafts mandatory to follow?

** Section 11

  The authors would like to thank all reviewers, contributors and the
  working group for reviewing this document and providing useful
  comments and suggestions

(Editorial) Consider actually naming the parties who provided reviews or feedback that contributed to the document.

[Ballot discuss]
Thank you for the work on this document.

Please let me know if the working group has already had a discussion on the following references, it is entirely possible that this was discussed and agreed upon, in which case thank you for letting me know and pointing me to the discussion.

I believe the following references should be normative instead of informative.
- RFC 3985 (which is informational, so if we agree the IESG also has to approve the downref that hasn't been called out in IETF Last Call)
- RFC 3550

[Ballot comment]
This is non-blocking because I am not sure about the resolution. Hopefully discussion with the authors and the responsible AD will help.

I was puzzled to see the following paragraph in Section 7.2.2:

> The recovered clock MUST comply with the jitter and wander requirements applicable to the type of attachment circuit, specified in:
>
> [G.825] and [G.823] for SDH
>
> [GR253] for SONET
>
> [G.8261] for synchronous Ethernet
>
> [G.8251] for OTN

and at the same time all of these references are informative. I understand that depending on which of these you are considering, the others might be unnecessary to read, however with the requirement text I still feel those would have made more sense as normative references.

Note that a similar comment could be made for the following text in Section 3.2, motivating the need for [G.8262] and [G.8261.1] being normative:

> While using external timing inputs (aka BITS [ATIS-0900105.09.2013]) or synchronous Ethernet as defined in [G.8261] the characteristics and limits defined in [G.8262] have to be considered.
>
> While relying on precision time protocol (PTP) as defined in [G.8265.1], the network limits defined in [G.8261.1] have to be considered.

[Ballot comment]
Thanks for addressing my previous DISCUSS for the -12 and considering my comments below (kept for archiving purposes).

The previous DISCUSS is archived at: https://mailarchive.ietf.org/arch/msg/pals/Spfarc0uyWsYjw63YB5HLytlkXA/

## COMMENTS (non-blocking) for archiving purpose only

### Added latency

Should there be some guidance about the added latency due to the packetization (could be reduced with packet size) and jitter buffer size ?

### Abstract & section 1

s/This document describes/This document specifies/ in a PS ;-)

Is `high-speed bit-streams` really part of this specification ? I.e., this technique could also be used with really slow links.

### Section 1

Suggest to expand PE at first use even if it is a knows acronym as it is expanded later in the text.

s/Ethernet connected/Ethernet-connected/ ?

What is `Synchronous Ethernet`, honestly I do not know, hence an informative reference is welcome.

Should there be an informational reference to `Fibre Channel` ?

A graphic for the SONET/SDH explanations would add to the text (even if the text is clear as it is). Just a suggestion.

`PDH` is not yet expanded at this point.

### Section 3.1

Just a suggestion for the reader, keep this section but also expand the acronyms at first use (because then they are more understandable -- few readers will read and understand a terminology section that only contains expansions without explanations).

### Section 3.2

s/The local oscillators C/The local clock C/ ?

Is it clock or frequency in `frequency synchronization available`? Because the word frequency was never used before.

A reference (more than the expansion of section 3.1) for `BITS` will be welcome.

### Section 5.1

Isn't it obvious that C-SID can be used ? => suggest removing this sentence (feel free to ignore).

Suggest to have a sub-section for the SRv6 behaviours.

s/The next header field of the SRH or last extension header/The next header field of the SRH or *the* last extension header/

s/The push of the SRH/The *insertion* of the SRH/ also add "per RFC 8986".

What is `pushed IPv6 header` ? If this is the SRH, then let's be clear (and BTW IPv6 is not MPLS, there is no "push" ;-) ).

### Section 7.2.1

Suggest to make it clear that all packets are of the same size in `fixed size PLE payloads`

### Section 10

Suggest to add (e.g., via a reference) the URI of the IANA (sub)registries.

Also, there is no `Segment Routing Parameters`, only a `Segment Routing` one ;-)

## NITS (non-blocking / cosmetic)

### Use of SVG

Suggest trying the "aasvg" tool to have nicer graphics in HTML/PDF rendering (worth a try).

### ethernet

Check that Ethernet is always capitalised.

[Ballot comment]
In general, I found this draft to be easier to follow than some.

Thanks to Christian Huitema for his security review.  I recommend that the rewrite of the Security Considerations paragraph
outlined here:  https://mailarchive.ietf.org/arch/msg/pals/lALbFW32nmmBVVAG68K7xLRUDZ8/ be considered.

[Ballot comment]
Thanks for this document. Minor comments:

Section 3.1 'Terminology' - 'SRH - Segment Routing Header' is defined in RFC 8754 NOT RFC 8402.

Section 3.1 'Terminology' - 'SR-TE - Segment Routing Traffic Engineering [RFC9256]'. RFC 9256 defines Segment Routing Policy Architecture. Please use a reference that accurately reflects where you use the SR-TE term.

[Ballot comment]
Thanks for this document. Minor comments:

Section 3.1 'Terminology' - 'SRH - Segment Routing Header' is defined in RFC 8754 NOT RFC 8402.
Section 3.1 'Terminology' - 'SR-TE - Segment Routing Traffic Engineering [RFC9256]'. RFC 9256 defines Segment Routing Policy Architecture. Please use a reference that accurately reflects where you use the SR-TE term.

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-pals-ple-12
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (trivial to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Stewart Bryant for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 2

When using the BCP 14 template, please use the most recent one. I told you that it was trivial to fix ;-)

[Ballot comment]

## COMMENTS (non-blocking)

### Added latency

Should there be some guidance about the added latency due to the packetization (could be reduced with packet size) and jitter buffer size ?

### Abstract & section 1

s/This document describes/This document specifies/ in a PS ;-)

Is `high-speed bit-streams` really part of this specification ? I.e., this technique could also be used with really slow links.

### Section 1

Suggest to expand PE at first use even if it is a knows acronym as it is expanded later in the text.

s/Ethernet connected/Ethernet-connected/ ?

What is `Synchronous Ethernet`, honestly I do not know, hence an informative reference is welcome.

Should there be an informational reference to `Fibre Channel` ?

A graphic for the SONET/SDH explanations would add to the text (even if the text is clear as it is). Just a suggestion.

`PDH` is not yet expanded at this point.

### Section 3.1

Just a suggestion for the reader, keep this section but also expand the acronyms at first use (because then they are more understandable -- few readers will read and understand a terminology section that only contains expansions without explanations).

### Section 3.2

s/The local oscillators C/The local clock C/ ?

Is it clock or frequency in `frequency synchronization available`? Because the word frequency was never used before.

A reference (more than the expansion of section 3.1) for `BITS` will be welcome.

### Section 5.1

Isn't it obvious that C-SID can be used ? => suggest removing this sentence (feel free to ignore).

Suggest to have a sub-section for the SRv6 behaviours.

s/The next header field of the SRH or last extension header/The next header field of the SRH or *the* last extension header/

s/The push of the SRH/The *insertion* of the SRH/ also add "per RFC 8986".

What is `pushed IPv6 header` ? If this is the SRH, then let's be clear (and BTW IPv6 is not MPLS, there is no "push" ;-) ).

### Section 7.2.1

Suggest to make it clear that all packets are of the same size in `fixed size PLE payloads`

### Section 10

Suggest to add (e.g., via a reference) the URI of the IANA (sub)registries.

Also, there is no `Segment Routing Parameters`, only a `Segment Routing` one ;-)

## NITS (non-blocking / cosmetic)

### Use of SVG

Suggest trying the "aasvg" tool to have nicer graphics in HTML/PDF rendering (worth a try).

### ethernet

Check that Ethernet is always capitalised.

[Ballot discuss]
Internet AD comments for draft-ietf-pals-ple-10
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

### S5.1

* "The next header field of the SRH MUST be set to TBA1."

  Technically this should only apply when there are no intervening extension
  headers between the SRH and the "upper layer header".

  Per RFC 8200 S4.1, there are a fair number of number of extension headers
  that are permitted.

  This document may RECOMMEND that there be no extension headers between
  the SRH and the PLE (upper layer) header, but it cannot forbid them (not
  without considering updating 8200 and/or 8754).

[Ballot comment]
# Internet AD comments for draft-ietf-pals-ple-10
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3.1

* "ICMP - Internet Control Message Protocol [RFC792]"

  Since the only use of ICMP in this document is in describing SRv6 Network
  Programming SRH processing, the ICMP reference you probably want is
  actually ICMPv6, which is RFC 4443.

### S5.1

* "The push of the SRH MAY be omitted when the SRv6 policy only
  contains one segment."

  You might append "and no optional TLVs in the SRH are desired, e.g.
  HMAC TLV."

  This applies to both bullets with identical text.

### S5.2.2

* "Sequence number ... MUST be ... MAY be ..."

  I'm not sure it's a good use of MUST to say something MUST be 'x' but MAY
  be 'y'. Can this be reworded into a SHOULD or a "MUST follow one the
  following two numbering schemes:"?

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was a relatively small response to WGLC but this is a specialist technology
and in the light of this the number of responses was satisfactory.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no points of controversy in the LC process.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None that I am aware of.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This protocol is in the shipping code of one major vendor with deployments underway.
There is a demo implementation by another major vendor that was exhibited at an
industry conference.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The technology acts as a carrier for IEEE, Fibre Channel and ITU-T protocols
and we do not foresee any adverse interaction. This WG has considerable experience
at transporting third-party physical and datalink protocols over IETF technologies.

I am sure that the SRv6 technology will be reviewed during the normal IETF review
process so nothing special is needed.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes it is.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

IPv6 Extensions header/next protocol request needs to be reviewed.
SRv6 network programming should be validated.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is indicated and this is appropriate.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes we have.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes they have (via the IPR disclosure request) and there are five authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are two minor nits that have been reported that we have not been able to track
down, but this should not delay the document proceeding to the next stage of
the IETF process.

The downrefs are to specifications published by other SDOs and can thus be
considered to be suitable normative references.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The listing of references is correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

There are none

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no RFCs that are DOWNREFs

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

I-D.draft-ietf-spring-srv6-srh-compression is a work item in SPRING that is
in IESG review.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is in the correct format, the IANA items correctly referenced
and listed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are none.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was a relatively small response to WGLC but this is a specialist technology
and in the light of this the number of responses was satisfactory.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no points of controversy in the LC process.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None that I am aware of.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This protocol is in the shipping code of one major vendor with deployments underway.
There is a demo implementation by another major vendor that was exhibited at an
industry conference.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The technology acts as a carrier for IEEE, Fibre Channel and ITU-T protocols
and we do not foresee any adverse interaction. This WG has considerable experience
at transporting third-party physical and datalink protocols over IETF technologies.

I am sure that the SRv6 technology will be reviewed during the normal IETF review
process so nothing special is needed.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes it is.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

IPv6 Extensions header/next protocol request needs to be reviewed.
SRv6 network programming should be validated.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is indicated and this is appropriate.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes we have.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes they have (via the IPR disclosure request) and there are five authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are two minor nits that have been reported that we have not been able to track
down, but this should not delay the document proceeding to the next stage of
the IETF process.

The downrefs are to specifications published by other SDOs and can thus be
considered to be suitable normative references.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The listing of references is correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No, there are not.

Those concerned with the detail of this draft would have access to those
specifications and the use of this reference has been allowed in IETF RFCs
for example: RFC3255, RFC3592, RFC4842 and RFC5143

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no RFCs that are DOWNREFs

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

I-D.draft-ietf-spring-srv6-srh-compression is a work item in SPRING that is
in IESG review.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is in the correct format, the IANA items correctly referenced
and listed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are none.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pals-ple-08. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Assigned Internet Protocol Numbers in the Protocol Numbers registry group located at:

https://www.iana.org/assignments/protocol-numbers/

a single new registration is to be made as follows:

Decimal: [ TBD-at-Registration ]
Keyword: BIT-EMU
Protocol: Bit-stream Emulation
IPv6 Extension Header: Y
Reference: [ RFC-to-be ]

Second, in the SRv6 Endpoint Behaviors registry in the Segment Routing registry group located at:

https://www.iana.org/assignments/segment-routing/

three existing registrations made by this document are to be updated as follows:

Value: 158
Hex: 0x009E
Endpoint Behavior: End.DX1
Reference: [ RFC-to-be ]
Change Controller: IETF

Value: 159
Hex: 0x009F
Endpoint Behavior: End.DX1 with NEXT-CSID
Reference: [ RFC-to-be ]
Change Controller: IETF

Value: 160
Hex: 0x00A0
Endpoint Behavior: End.DX1 with REPLACE-CSID
Reference: [ RFC-to-be ]
Change Controller: IETF

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was a relatively small response to WGLC but this is a specialist technology
and in the light of this the number of responses was satisfactory.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no points of controversy in the LC process.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None that I am aware of.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This protocol is in the shipping code of one major vendor with deployments underway.
There is a demo implementation by another major vendor that was exhibited at an
industry conference.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The technology acts as a carrier for IEEE, Fibre Channel and ITU-T protocols
and we do not foresee any adverse interaction. This WG has considerable experience
at transporting third-party physical and datalink protocols over IETF technologies.

I am sure that the SRv6 technology will be reviewed during the normal IETF review
process so nothing special is needed.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes it is.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

IPv6 Extensions header/next protocol request needs to be reviewed.
SRv6 network programming should be validated.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is indicated and this is appropriate.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes we have.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes they have (via the IPR disclosure request) and there are five authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are two minor nits that have been reported that we have not been able to track
down, but this should not delay the document proceeding to the next stage of
the IETF process.

The downrefs are to specifications published by other SDOs and can thus be
considered to be suitable normative references.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The listing of references is correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The following reference is available but needs to be purchased:

  [GR253]    Telcordia, "SONET Transport Systems - Common Generic
              Criteria", October 2009.

Those concerned with the detail of this draft would have access to those
specifications and the use of this reference has been allowed in IETF RFCs
for example: RFC3255, RFC3592, RFC4842 and RFC5143

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no RFCs that are DOWNREFs

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

I-D.draft-ietf-spring-srv6-srh-compression is a work item in SPRING that is
in IESG review.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is in the correct format, the IANA items correctly referenced
and listed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are none.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was a relatively small response to WGLC but this is a specialist technology
and in the light of this the number of responses was satisfactory.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no points of controversy in the LC process.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None that I am aware of.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This protocol is in the shipping code of one major vendor with deployments underway.
There is a demo implementation by another major vendor that was exhibited at an
industry conference.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The technology acts as a carrier for IEEE, Fibre Channel and ITU-T protocols
and we do not foresee any adverse interaction. This WG has considerable experience
at transporting third-party physical and datalink protocols over IETF technologies.

I am sure that the SRv6 technology will be reviewed during the normal IETF review
process so nothing special is needed.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes it is.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

IPv6 Extensions header/next protocol request needs to be reviewed.
SRv6 network programming should be validated.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is indicated and this is appropriate.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes we have.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes they have (via the IPR disclosure request) and there are five authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are two minor nits that have been reported that we have not been able to track
down, but this should not delay the document proceeding to the next stage of
the IETF process.

The downrefs are to specifications published by other SDOs and can thus be
considered to be suitable normative references.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The listing of references is correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The following reference is available but needs to be purchased:

  [GR253]    Telcordia, "SONET Transport Systems - Common Generic
              Criteria", October 2009.

Those concerned with the detail of this draft would have access to those
specifications and the use of this reference has been allowed in IETF RFCs
for example: RFC3255, RFC3592, RFC4842 and RFC5143

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no RFCs that are DOWNREFs

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

I-D.draft-ietf-spring-srv6-srh-compression is a work item in SPRING that is
in IESG review.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is in the correct format, the IANA items correctly referenced
and listed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are none.

The following Last Call announcement was sent out (ends 2024-10-23):

From: The IESG
To: IETF-Announce
CC: agmalis@gmail.com, draft-ietf-pals-ple@ietf.org, gunter@vandevelde.cc, pals-chairs@ietf.org, pals@ietf.org, stewart.bryant@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Private Line Emulation over Packet Switched Networks) to Proposed Standard


The IESG has received a request from the Pseudowire And LDP-enabled Services
WG (pals) to consider the following document: - 'Private Line Emulation over
Packet Switched Networks'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-10-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes methods and requirements for implementing the
  encapsulation of high-speed bit-streams into virtual private wire
  services (VPWS) over packet switched networks (PSN) providing
  complete signal transport transparency.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pals-ple/



No IPR declarations have been submitted directly on this I-D.

Addressing the AD's concern that the lack of freely accessible normative references behind a paywall, particularly during the review period, may result in complications, the authors and PALS co-chairs will work to reclassify the relevant normative references as informative references.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was a relatively small response to WGLC but this is a specialist technology
and in the light of this the number of responses was satisfactory.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no points of controversy in the LC process.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None that I am aware of.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This protocol is in the shipping code of one major vendor with deployments underway.
There is a demo implementation by another major vendor that was exhibited at an
industry conference.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The technology acts as a carrier for IEEE, Fibre Channel and ITU-T protocols
and we do not foresee any adverse interaction. This WG has considerable experience
at transporting third-party physical and datalink protocols over IETF technologies.

I am sure that the SRv6 technology will be reviewed during the normal IETF review
process so nothing special is needed.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes it is.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

IPv6 Extensions header/next protocol request needs to be reviewed.
SRv6 network programming should be validated.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is indicated and this is appropriate.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes we have.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes they have (via the IPR disclosure request) and there are five authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are two minor nits that have been reported that we have not been able to track
down, but this should not delay the document proceeding to the next stage of
the IETF process.

The downrefs are to specifications published by other SDOs and can thus be
considered to be suitable normative references.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The listing of references is correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

  [FC-PI-2]  INCITS, "Information Technology - Fibre Channel Physical
              Interfaces - 2 (FC-PI-2)", 2006,
              .

  [FC-PI-5]  INCITS, "Information Technology - Fibre Channel - Physical
              Interface-5 (FC-PI-5)", 2011,
              .

  [FC-PI-5am1]
              INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 5/Amendment 1 (FC-PI-5/AM1)", 2016,
              .

  [FC-PI-6]  INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 6 (FC-PI-6)", 2015,
              .

  [FC-PI-6P] INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 6P (FC-PI-6P)", 2016,
              .

  [FC-PI-7]  INCITS, "Information Technology – Fibre Channel - Physical
              Interfaces - 7 (FC-PI-7)", 2021,
              .

  [GR253]    Telcordia, "SONET Transport Systems - Common Generic
              Criteria", October 2009.

Those concerned with the detail of this draft would have access to those
specifications.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Only third party standards.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

I-D.draft-ietf-spring-srv6-srh-compression is a work item in SPRING and is in
early formal review stage.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is in the correct format, the IANA items correctly referenced
and listed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are none.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was a relatively small response to WGLC but this is a specialist technology
and in the light of this the number of responses was satisfactory.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no points of controversy in the LC process.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None that I am aware of.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This protocol is in the shipping code of one major vendor with deployments underway.
There is a demo implementation by another major vendor that was exhibited at an
industry conference.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The technology acts as a carrier for IEEE, Fibre Channel and ITU-T protocols
and we do not foresee any adverse interaction. This WG has considerable experience
at transporting third-party physical and datalink protocols over IETF technologies.

I am sure that the SRv6 technology will be reviewed during the normal IETF review
process so nothing special is needed.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes it is.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

IPv6 Extensions header/next protocol request needs to be reviewed.
SRv6 network programming should be validated.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is indicated and this is appropriate.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes we have.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes they have (via the IPR disclosure request) and there are five authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are two minor nits that have been reported that we have not been able to track
down, but this should not delay the document proceeding to the next stage of
the IETF process.

The downrefs are to specifications published by other SDOs and can thus be
considered to be suitable normative references.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The listing of references is correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

  [FC-PI-2]  INCITS, "Information Technology - Fibre Channel Physical
              Interfaces - 2 (FC-PI-2)", 2006,
              .

  [FC-PI-5]  INCITS, "Information Technology - Fibre Channel - Physical
              Interface-5 (FC-PI-5)", 2011,
              .

  [FC-PI-5am1]
              INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 5/Amendment 1 (FC-PI-5/AM1)", 2016,
              .

  [FC-PI-6]  INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 6 (FC-PI-6)", 2015,
              .

  [FC-PI-6P] INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 6P (FC-PI-6P)", 2016,
              .

  [FC-PI-7]  INCITS, "Information Technology – Fibre Channel - Physical
              Interfaces - 7 (FC-PI-7)", 2021,
              .

  [GR253]    Telcordia, "SONET Transport Systems - Common Generic
              Criteria", October 2009.

Those concerned with the detail of this draft would have access to those
specifications.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Only third party standards.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

I-D.draft-ietf-spring-srv6-srh-compression is a work item in SPRING and is in
early formal review stage.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is in the correct format, the IANA items correctly referenced
and listed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are none.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was a relatively small response to WGLC but this is a specialist technology
and in the light of this the number of responses was satisfactory.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no points of controversy in the LC process.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None that I am aware of.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This protocol is in the shipping code of one major vendor with deployments underway.
There is a demo implementation by another major vendor that was exhibited at an
industry conference.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The technology acts as a carrier for IEEE, Fibre Channel and ITU-T protocols
and we do not foresee any adverse interaction. This WG has considerable experience
at transporting third-party physical and datalink protocols over IETF technologies.

I am sure that the SRv6 technology will be reviewed during the normal IETF review
process so nothing special is needed.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes it is.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

IPv6 Extensions header/next protocol request needs to be reviewed.
SRv6 network programming should be validated.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is indicated and this is appropriate.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes we have.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes they have (via the IPR disclosure request) and there are five authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are two minor nits that have been reported that we have not been able to track
down, but this should not delay the document proceeding to the next stage of
the IETF process.

The downrefs are to specifications published by other SDOs and can thus be
considered to be suitable normative references.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The listing of references is correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

  [FC-PI-2]  INCITS, "Information Technology - Fibre Channel Physical
              Interfaces - 2 (FC-PI-2)", 2006,
              .

  [FC-PI-5]  INCITS, "Information Technology - Fibre Channel - Physical
              Interface-5 (FC-PI-5)", 2011,
              .

  [FC-PI-5am1]
              INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 5/Amendment 1 (FC-PI-5/AM1)", 2016,
              .

  [FC-PI-6]  INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 6 (FC-PI-6)", 2015,
              .

  [FC-PI-6P] INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 6P (FC-PI-6P)", 2016,
              .

  [FC-PI-7]  INCITS, "Information Technology – Fibre Channel - Physical
              Interfaces - 7 (FC-PI-7)", 2021,
              .

  [GR253]    Telcordia, "SONET Transport Systems - Common Generic
              Criteria", October 2009.

Those concerned with the detail of this draft would have access to those
specifications.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Only third party standards.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

I-D.draft-ietf-spring-srv6-srh-compression is a work item in SPRING and is in
early formal review stage.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA section is in the correct format, the IANA items correctly referenced
and listed.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are none.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was a relatively small response to WGLC but this is a specialist technology
and in the light of this the number of responses was satisfactory.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no points of controversy in the LC process.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

None that I am aware of.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

I am not sure if there are any implementations but it is common in this area to
find that vendors wait for the RFC before implimenting. There is vendor and operator
interest in this type of PW.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The technology acts as a carrier for IEEE and ITU-T protocols but I doubt that
there would be any adverse interaction.

I am sure that the SRv6 technology will be reviewed during the normal IETF review
process so nothing special is needed.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes it is.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

IPv6 Extensions header/next protocol request needs to be reviewed.
SRv6 network programming should be validated.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is indicated and this is appropriate.


12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes we have.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes they have (via the IPR disclosure request) and there are five authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I am working with the authors to correct the last remaining nits

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Not as far as I can see.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
  [FC-PI-2]  INCITS, "Information Technology - Fibre Channel Physical
              Interfaces - 2 (FC-PI-2)", 2006,
              .

  [FC-PI-5]  INCITS, "Information Technology - Fibre Channel - Physical
              Interface-5 (FC-PI-5)", 2011,
              .

  [FC-PI-5am1]
              INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 5/Amendment 1 (FC-PI-5/AM1)", 2016,
              .

  [FC-PI-6]  INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 6 (FC-PI-6)", 2015,
              .

  [FC-PI-6P] INCITS, "Information Technology - Fibre Channel - Physical
              Interface - 6P (FC-PI-6P)", 2016,
              .

  [FC-PI-7]  INCITS, "Information Technology – Fibre Channel - Physical
              Interfaces - 7 (FC-PI-7)", 2021,
              .

  [GR253]    Telcordia, "SONET Transport Systems - Common Generic
              Criteria", October 2009.


17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

I-D.draft-ietf-spring-srv6-srh-compression is a work item in SPRING and is in
early formal review stage.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

I have suggested that the IPv6 description be change to reflect how it is laid out in the
registry, but all the required material is in place.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/