Skip to main content

Use of Multicast across Inter-domain Peering Points
draft-ietf-mboned-interdomain-peering-bcp-14

Revision differences

Document history

Date Rev. By Action
2018-01-04
14 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-01-02
14 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-12-20
14 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2017-12-12
14 (System) RFC Editor state changed to AUTH from EDIT
2017-11-11
14 (System) IANA Action state changed to No IC from In Progress
2017-11-11
14 (System) RFC Editor state changed to EDIT
2017-11-11
14 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-11-11
14 (System) Announcement was received by RFC Editor
2017-11-11
14 (System) IANA Action state changed to In Progress
2017-11-11
14 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2017-11-11
14 Cindy Morgan IESG has approved the document
2017-11-11
14 Cindy Morgan Closed "Approve" ballot
2017-11-11
14 Cindy Morgan Ballot approval text was generated
2017-11-11
14 Cindy Morgan Ballot writeup was changed
2017-11-10
14 Alissa Cooper [Ballot comment]
Thank for addressing my DISCUSS and COMMENTs.
2017-11-10
14 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2017-11-03
14 Kathleen Moriarty [Ballot comment]
Thanks for addressing my prior discuss and comments.
2017-11-03
14 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss
2017-11-03
14 Ben Campbell
[Ballot comment]
Thanks for addressing my DISCUSS point.

As a new editorial comment, I note that there are a few other mentions of "location" in …
[Ballot comment]
Thanks for addressing my DISCUSS point.

As a new editorial comment, I note that there are a few other mentions of "location" in the draft. It might be helpful to qualify those as "network location". But this is not a show stopper, since you did qualify it in the authoritative mention.
2017-11-03
14 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss
2017-10-31
14 Mirja Kühlewind
[Ballot comment]
Thanks for addressing my discuss and providing a detailed section on congestion control. And thanks Yoshi for the TSV-ART review again!

-----------------------------
Old …
[Ballot comment]
Thanks for addressing my discuss and providing a detailed section on congestion control. And thanks Yoshi for the TSV-ART review again!

-----------------------------
Old questions/comments:

1) Section 3.4 also says:
"Highly efficient use of bandwidth in AD-1."
But aren't packets eventually duplicated in this case in AD-1? I guess it's more efficient than replicating them at the network border but might be still less efficient than native multicast in the whole network, no?

2) section 4.3.3 says:
"The two AD's may supply additional security logs..."
This seems to be a general action not specific to multicast or the scenarios described in this doc.

3) I don't think the conclusion section (8) is helpful or needed. If you want to keep it at all, this text could be moved into the introduction.
2017-10-31
14 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2017-10-31
14 Mirja Kühlewind
[Ballot comment]
Thanks for addressing my discuss and provide a detailed section on congestion control. And thanks Yoshi for the TSV-ART review again!

-----------------------------
Old …
[Ballot comment]
Thanks for addressing my discuss and provide a detailed section on congestion control. And thanks Yoshi for the TSV-ART review again!

-----------------------------
Old questions/comments:

1) Section 3.4 also says:
"Highly efficient use of bandwidth in AD-1."
But aren't packets eventually duplicated in this case in AD-1? I guess it's more efficient than replicating them at the network border but might be still less efficient than native multicast in the whole network, no?

2) section 4.3.3 says:
"The two AD's may supply additional security logs..."
This seems to be a general action not specific to multicast or the scenarios described in this doc.

3) I don't think the conclusion section (8) is helpful or needed. If you want to keep it at all, this text could be moved into the introduction.
2017-10-31
14 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2017-10-30
14 Toerless Eckert New version available: draft-ietf-mboned-interdomain-peering-bcp-14.txt
2017-10-30
14 (System) New version approved
2017-10-30
14 (System) Request for posting confirmation emailed to previous authors: Toerless Eckert , Ram Krishnan , Percy Tarapore , Greg Shepherd , Robert Sayko
2017-10-30
14 Toerless Eckert Uploaded new revision
2017-10-27
13 Toerless Eckert New version available: draft-ietf-mboned-interdomain-peering-bcp-13.txt
2017-10-27
13 (System) New version approved
2017-10-27
13 (System) Request for posting confirmation emailed to previous authors: Ram Krishnan , Greg Shepherd , Percy Tarapore , Toerless Eckert , mboned-chairs@ietf.org, Robert Sayko
2017-10-27
13 Toerless Eckert Uploaded new revision
2017-10-27
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-10-27
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-10-27
12 Toerless Eckert New version available: draft-ietf-mboned-interdomain-peering-bcp-12.txt
2017-10-27
12 (System) New version approved
2017-10-27
12 (System) Request for posting confirmation emailed to previous authors: Ram Krishnan , Toerless Eckert , Percy Tarapore , Greg Shepherd , Robert Sayko
2017-10-27
12 Toerless Eckert Uploaded new revision
2017-10-12
11 Yoshifumi Nishida Request for Telechat review by TSVART Completed: Almost Ready. Reviewer: Yoshifumi Nishida.
2017-10-12
11 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2017-10-12
11 Mirja Kühlewind
[Ballot discuss]
Sorry for this last minute discuss but I would like to emphasize the points made in the tsv-art review on congestion/rate control (Thanks …
[Ballot discuss]
Sorry for this last minute discuss but I would like to emphasize the points made in the tsv-art review on congestion/rate control (Thanks Yoshi!):

Please provide stronger guidance (MUST) on the use of rate/congestion control in these two cases:

In Section 3.1:
    " If the peering point between AD-1 and AD-2 is a controlled
  network environment, then bandwidth can be allocated
  accordingly by the two domains to permit the transit of non-
  rate adaptive multicast traffic. If this is not the case, then
  it is recommended that the multicast traffic should support
  rate-adaption."

In Section 4.1,
    "When determining the appropriate bandwidth allocation, parties should consider use
      of a multicast protocol suitable for live video streaming that
      is consistent with Congestion Control Principles [BCP41]."
2017-10-12
11 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to Discuss from No Objection
2017-10-11
11 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-10-11
11 Adam Roach
[Ballot comment]
I support Alissa's and Kathleen's DISCUSSes; and (as a separate concern), I support Ben's DISCUSS.

Most of the comments I noted in my …
[Ballot comment]
I support Alissa's and Kathleen's DISCUSSes; and (as a separate concern), I support Ben's DISCUSS.

Most of the comments I noted in my review of this document have been made by other reviewers, and I will not reiterate most of them. I would, however, like to draw particular attention to Ben's comments regarding charging, billing, and settlement -- I believe these issues should either be fleshed out in significantly more detail, or removed (with a simple statement in the introduction that such issues are generally out of scope for the entire document).

___

Section 4.2.3 contains the following text:

    (Note
    that in IPv6 there is a specific Anycast format and Anycast is
    inherent in IPv6 routing, whereas in IPv4 Anycast is handled via
    provisioning in the network. Details are out of scope for this
    document.)

It would be helpful to the reader if the "out of scope" statement were accompanied by a pointer to BCP 126/RFC 4786.

___

Section 5 contains the following text:

  It is expected that multicast diagnostics will be collected
  according to currently established practices [MDH-04].

I believe this statement makes [MDH-04] normative, as it is required to understand its contents to implement the recommendations in this BCP.
2017-10-11
11 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2017-10-11
11 Eric Rescorla
[Ballot comment]
I support Kathleen's and Alissa's discusses

I'm concerned about whether the practices described adequately capture the notion of user consent to receive the …
[Ballot comment]
I support Kathleen's and Alissa's discusses

I'm concerned about whether the practices described adequately capture the notion of user consent to receive the data. Specifically, we're talking about sending large streams of data to people. Do the protocols in question adequately ensure that the addresses in question wish to receive the data. Specifically, the issue I am concerned with is whether I can cause you to get a large video stream. I'm filing this as a Comment rather than a Discuss because it doesn't seem like an issue for this BCP but rather for the protocols it documents.

Please define S,G at first use.
2017-10-11
11 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2017-10-11
11 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-10-11
11 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2017-10-11
11 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2017-10-11
11 Martin Stiemerling Request for Telechat review by TSVART is assigned to Yoshifumi Nishida
2017-10-11
11 Martin Stiemerling Request for Telechat review by TSVART is assigned to Yoshifumi Nishida
2017-10-10
11 Ben Campbell
[Ballot discuss]
(This is related to Alissa's DISCUSS about logging of privacy-sensitive data. But since it's a little different, I'm entering my own DISCUSS.)

In …
[Ballot discuss]
(This is related to Alissa's DISCUSS about logging of privacy-sensitive data. But since it's a little different, I'm entering my own DISCUSS.)

In section 4.4 (operations) the bullet on problem notification states that AD2 will inform AD1 of, among other things, the locations of users. Is that intended to be geolocation, or network location? If the former, that's extremely sensitive information, and needs privacy guidelines.
2017-10-10
11 Ben Campbell
[Ballot comment]
Substantive Comments:

- I support Alissa's and Kathleen's DISCUSS positions.

- There seem to be quite a few implied assumptions about business models. …
[Ballot comment]
Substantive Comments:

- I support Alissa's and Kathleen's DISCUSS positions.

- There seem to be quite a few implied assumptions about business models. I will call out some specifically, but I'm sure I didn't catch them all. These assumptions should either be removed or made explicit.

- The lists of guidelines seem to mix guidelines with observations of fact. This makes it difficult to tell which parts are "best practices" (that is, recommendations) vs which parts simply state fact.

-2: Is the assumption that the source is a service provider and the consumer is an end-user relevant? This seems to perpetuate the (often false) assumption that end users only consume content, but never produce it. It would be better to state this in the form of whatever assumptions are implied by the idea of SPs and EUs.  For example, do you assume there is a one to many relationship between SPs and EUs?

-3.2: Why does this section not rate a figure? I think it would be helpful to show the GRE tunnel as distinct from the native multicast.

-3.5, paragraph after Figure 4: The large number of tunnels implies some assumptions about the cardinality between SPs and EUs that should be stated explicitly. (It would help to show this in the figures.)

- 4.3.2: The idea that that AD1 has a need to identify users in AD2 seems to be based on some implied business model assumptions. Please state those explicitly. (Or if I missed where they are stated, please point out the text.)

-4.3.3: This states that logging is necessary for delivery. Why is that? Again, this seems to make some implicit business model assumptions. This section also needs explicit privacy considerations.

-4.4: The choice of monitoring, etc, seems to be up to the network operators to decide. Why does this document need to "expect" that? It might be helpful to describe how monitoring specific information could be useful (perhaps for troubleshooting), but the document does not go into that. The statements about compensation should be out of scope for an IETF document.

-5: Can you define, or reference a definition for, "Looking-Glass style".

-6: Please include a discussion of threat models. When might one choose to encrypt or not encrypt? What risks exist if you don't encrypt?

-- : "DRM and Application Accounting, Authorization and Authentication should be the responsibility of the multicast application source"
Why? This seems to imply some business model assumptions.










Editorial Comments:

- General: I find the heavy use of nested bullet lists hard to read. Much of the information in the lists would be better suited to paragraph form, especially when list entries span several sentences.  Likewise, the inconsistent use of full sentences vs fragments makes it hard to read. (Maybe this is just me)

-2: Please explain (s,g) before using, or even better spell it out. You do, in fact, explain it in 4.2.3, but it's used quite a bit before you get to there.

-3.2, third bullet: "Ability to support only partial IP multicast deployments..."
Does this mean "only able to support partial..." or "able to support partial..."?

- 3.3, figure:
The figures that involve tunnels would be easier to understand if you visually distinguished tunnels from non-tunneled links.

- 3.3, e: "AMT tunnels will then configure dynamically"
s/configure/"be configured"

-3.4, d: " It is recommended that proper procedures are implemented such
    that the AMT Gateway at the End User device is able to find the
    correct AMT Relay..."
Is that a recommendation or a requirement necessary to work at all? (Same construction appears in at least 3.5).

-4.1: Please expand SLA on first use.

-4.2.3: AMT Gateway: "The Gateway will reside on an End-Point - this
        may be a Personal Computer (PC) or a Set Top Box (STB)."
Is that meant to be exhaustive? Surely there are endpoints that do not resemble PCs or STBs.

-4.2.3, example procedures for gateway selection:
The heavy use of passive voice in this section obscures the actors. (This is true to some degree throughout the document, but it seems more confusing here.)

-4.3.2, 2nd bullet: Please don't use "/" as shorthand for conjunctions.  (Pattern repeats throughout the rest of the draft.)

-4.3.3, first paragraph: The first sentence is hard to parse.

-6: Please expand DRM and CDN on first mention.
2017-10-10
11 Ben Campbell [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell
2017-10-10
11 Spencer Dawkins
[Ballot comment]
Thanks for doing this work.

I have comments, but they're all editorial.

In this text,

    o AD-1 and AD-2 are assumed …
[Ballot comment]
Thanks for doing this work.

I have comments, but they're all editorial.

In this text,

    o AD-1 and AD-2 are assumed to adopt compatible protocols. The
        use of different protocols is beyond the scope of this
        document.

"compatible protocols" isn't helpful without some context. Is this talking about "compatible multicast protocols", or complete protocol stacks from IP on up, or something else?

I'm also noticing that the terms "should" and "recommended" appear a few times in this document. This is a BCP and doesn't reference BCP 14, which is all fine, but the wording is likely to lead readers in one direction. I wonder if it's helpful to say these things differently, so that (for instance)

        Hence, in the case of inter-domain peering, it is
        recommended to use only SSM protocols; the setup of inter-
        domain peering for ASM (Any-Source Multicast) is not in scope
        for this document.

might become

        Hence, this document assumes that in the case of inter-domain
        peering, only SSM protocols are used; the setup of inter-
        domain peering for ASM (Any-Source Multicast) is not in scope
        for this document.

Nit: "out of cope"

This text,

        packet streams will be part of a suitable
        multicast transport protocol.

didn't parse for me - was it saying

      packet streams will be carried by a suitable
      multicast transport protocol.

or something else?

In this text,

  Note that domain 2 may be an independent network domain (e.g., Tier
  1 network operator domain). Alternately, domain 2 could also be an
  Enterprise network domain operated by a single customer. The peering
  point architecture and requirements may have some unique aspects
  associated with the Enterprise case.

  The Use Cases describing various architectural configurations for
  the multicast distribution along with associated requirements is
  described in section 3. Unique aspects related to the Enterprise
  network possibility will be described in this section. Section 4
  contains a comprehensive list of pertinent information that needs to
  be exchanged between the two domains in order to support functions
  to enable the application transport.

it wasn't easy for me to tie "some unique aspects" in the first paragraph to "will be described in this section" in the second - if the last sentence in the first paragraph was moved to be the second paragraph, so the text was

  Note that domain 2 may be an independent network domain (e.g., Tier
  1 network operator domain). Alternately, domain 2 could also be an
  Enterprise network domain operated by a single customer.

  The Use Cases describing various architectural configurations for
  the multicast distribution along with associated requirements is
  described in section 3. The peering
  point architecture and requirements may have some unique aspects
  associated with the Enterprise case. These unique aspects will be
  described in this section. Section 4
  contains a comprehensive list of pertinent information that needs to
  be exchanged between the two domains in order to support functions
  to enable the application transport.

that would have been easier for me to follow. It's also worth mentioning that I'm guessing that "section 3" is "this section" in that text, and I'm pretty sure "this section" isn't "section 2", which is actually where the sentence appears, but it might be easier for the reader to say "will also be described in section 3".

The first sentence in

    e. The interconnection of AD-1 and AD-2 should, at a minimum,
        follow guidelines for traffic filtering between autonomous
        systems [BCP38]. Filtering guidelines specific to the multicast
        control-plane and data-plane are described in section 6.

just seems odd ("this BCP says you should do that BCP"). ISTM that if there are multicast-specific reasons to do BCP38 in addition to the usual reasons, that would be a fine thing to say here, of course.

If your audience doesn't already know

    o The GRE tunnel is often left pinned up.

(and if they don't, thank you for telling them), you might want to add a few words explaining why that's a disadvantage.

In this text,

  The advantage for such a chained set of AMT tunnels is that the
  total number of unicast streams across AD-2 is significantly
  reduced, thus freeing up bandwidth. Additionally, there will be a
  single unicast stream across the peering point instead of possibly,
  an unacceptably large number of such streams per Use Case 3.4.
  However, this implies that several AMT tunnels will need to be
  dynamically configured by the various AMT Gateways based solely on
  the (S,G) information received from the application client at the EU
  device. A suitable mechanism for such dynamic configurations is
  therefore critical.

is there a good reference for "suitable mechanism(s)"?
2017-10-10
11 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-10-10
11 Kathleen Moriarty
[Ballot discuss]
Thanks for your work on this draft.  I'd like to see some text clarifications on security recommendations that should not be difficult to …
[Ballot discuss]
Thanks for your work on this draft.  I'd like to see some text clarifications on security recommendations that should not be difficult to resolve.

Section 4.4 - the exchange of supporting information could be sensitive, are there security requirements on the exchange?  I don’t see them in this section.

Section 6 - For the following text, it would be helpful to see some recommendations:
  “DRM and Application Accounting, Authorization and Authentication
  should be the responsibility of the multicast application source
  provider and/or AD-1. AD-1 needs to work out the appropriate
  agreements with the source provider.”
2017-10-10
11 Kathleen Moriarty
[Ballot comment]
I agree with and support Alissa's Discuss and comments.  Since she already holds a discuss on this point, here are my comments:
Section …
[Ballot comment]
I agree with and support Alissa's Discuss and comments.  Since she already holds a discuss on this point, here are my comments:
Section 4.3.3 clearly refers to different types of logs, some have well known methods of delivery (syslog) and authentication, but setting a minimum requirement for secure exchange including encryption and authentication should be included in this section. The protocols and options may vary between the log types.
2017-10-10
11 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2017-10-10
11 Alissa Cooper
[Ballot discuss]
Section 4.3.3 recommends that ADs generate and exchange extensive logging information, but the document says nothing about securing these logs or limiting the …
[Ballot discuss]
Section 4.3.3 recommends that ADs generate and exchange extensive logging information, but the document says nothing about securing these logs or limiting the exchange of private or confidential information between the peers. This seems like it needs to be addressed in the BCP.
2017-10-10
11 Alissa Cooper
[Ballot comment]
(1) Why does this document contain the copyright disclaimer for pre-RFC5378 work?

(2) Section 4.4 says:

"In the event of performance degradation (SLA …
[Ballot comment]
(1) Why does this document contain the copyright disclaimer for pre-RFC5378 work?

(2) Section 4.4 says:

"In the event of performance degradation (SLA violation), AD-1
        may have to compensate the multicast application source per SLA
        agreement. As appropriate, AD-1 may seek compensation from AD-2
        if the cause of the degradation is in AD-2's network."

and

"Faults in service could lead to SLA violation for which the
        multicast application source provider may have to be
        compensated by AD-1. Subsequently, AD-1 may have to be
        compensated by AD-2 based on the contract."
   
These bullets seem out of scope for this BCP. I would recommend deleting them.

(3) Section 6 says:

"DRM and Application Accounting, Authorization and Authentication
  should be the responsibility of the multicast application source
  provider and/or AD-1. AD-1 needs to work out the appropriate
  agreements with the source provider.

  Network has no DRM responsibilities, but might have authentication
  and authorization obligations. These though are consistent with
  normal operations of a CDN to insure end user reliability, security
  and network security."

I find these two paragraphs somewhat contradictory and vague. The first paragraph makes it sound like DRM could be the responsibility of AD-1. The second paragraph makes it sound like AD-1 (assuming it counts as "network") would never be responsible for DRM. Then later on the text says:

"Authentication and authorization of EU to receive multicast content
  is done at the application layer between the client application and
  the source. This may involve some kind of token authentication and
  is done at the application layer independently of the two AD's."

Is this differentiating authentication and authorization of the application source from that of the end user? It's not clear. I would suggest revising this whole section to be clear about which security functions are the responsibility of which parties.
2017-10-10
11 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2017-10-09
11 Mirja Kühlewind
[Ballot comment]
Minor questions/comments:

1) Section 3.4 also says:
"Highly efficient use of bandwidth in AD-1."
But aren't packets eventually duplicated in this case in …
[Ballot comment]
Minor questions/comments:

1) Section 3.4 also says:
"Highly efficient use of bandwidth in AD-1."
But aren't packets eventually duplicated in this case in AD-1? I guess it's more efficient than replicating them at the network border but might be still less efficient than native multicast in the whole network, no?

2) section 4.3.3 says:
"The two AD's may supply additional security logs..."
This seems to be a general action not specific to multicast or the scenarios described in this doc.

3) I don't think the conclusion section (8) is helpful or needed. If you want to keep it at all, this text could be moved into the introduction.
2017-10-09
11 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2017-10-09
11 Mirja Kühlewind Requested Telechat review by TSVART
2017-10-04
11 Christer Holmberg Request for Telechat review by GENART Completed: Ready. Reviewer: Christer Holmberg. Sent review to list.
2017-10-04
11 Jean Mahoney Request for Telechat review by GENART is assigned to Christer Holmberg
2017-10-04
11 Jean Mahoney Request for Telechat review by GENART is assigned to Christer Holmberg
2017-10-02
11 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2017-09-30
11 Warren Kumari IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2017-09-30
11 Warren Kumari Placed on agenda for telechat - 2017-10-12
2017-09-30
11 Warren Kumari Ballot has been issued
2017-09-30
11 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2017-09-30
11 Warren Kumari Created "Approve" ballot
2017-09-30
11 Warren Kumari Ballot writeup was changed
2017-09-30
11 Warren Kumari Changed consensus to Yes from Unknown
2017-09-28
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-09-28
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-09-28
11 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-11.txt
2017-09-28
11 (System) New version approved
2017-09-28
11 (System) Request for posting confirmation emailed to previous authors: Ram Krishnan , Toerless Eckert , Percy Tarapore , Greg Shepherd , Robert Sayko
2017-09-28
11 Percy Tarapore Uploaded new revision
2017-09-24
10 Warren Kumari WK: Checked progress -- 2017-09-24
2017-09-06
10 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Nevil Brownlee.
2017-09-04
10 Warren Kumari Waiting on IETF LC comments to be addressed.
2017-09-04
10 Warren Kumari IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2017-09-02
10 Christer Holmberg Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Christer Holmberg.
2017-08-23
10 Barry Leiba Request for Last Call review by SECDIR Completed: Ready. Reviewer: Barry Leiba. Sent review to list.
2017-08-23
10 Min Ye Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Tomonori Takeda.
2017-08-23
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-08-21
10 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2017-08-21
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-mboned-interdomain-peering-bcp-10, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-mboned-interdomain-peering-bcp-10, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
2017-08-15
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nevil Brownlee
2017-08-15
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nevil Brownlee
2017-08-14
10 Min Ye Request for Last Call review by RTGDIR is assigned to Tomonori Takeda
2017-08-14
10 Min Ye Request for Last Call review by RTGDIR is assigned to Tomonori Takeda
2017-08-10
10 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2017-08-10
10 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2017-08-10
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Barry Leiba
2017-08-10
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Barry Leiba
2017-08-09
10 Min Ye Request for Last Call review by RTGDIR is assigned to Henning Rogge
2017-08-09
10 Min Ye Request for Last Call review by RTGDIR is assigned to Henning Rogge
2017-08-09
10 Alvaro Retana Requested Last Call review by RTGDIR
2017-08-09
10 Amy Vezza IANA Review state changed to IANA - Review Needed
2017-08-09
10 Amy Vezza
The following Last Call announcement was sent out (ends 2017-08-23):

From: The IESG
To: IETF-Announce
CC: mboned@ietf.org, tim.chown@jisc.ac.uk, draft-ietf-mboned-interdomain-peering-bcp@ietf.org, warren@kumari.net, mboned-chairs@ietf.org …
The following Last Call announcement was sent out (ends 2017-08-23):

From: The IESG
To: IETF-Announce
CC: mboned@ietf.org, tim.chown@jisc.ac.uk, draft-ietf-mboned-interdomain-peering-bcp@ietf.org, warren@kumari.net, mboned-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Use of Multicast Across Inter-Domain Peering Points) to Best Current Practice


The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document: - 'Use of Multicast Across Inter-Domain
Peering Points'
  as Best Current Practice

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
ietf@ietf.org mailing lists by 2017-08-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 examines the use of Source Specific Multicast (SSM)
  across inter-domain peering points for a specified set of deployment
  scenarios. The objective is to describe the setup process for
  multicast-based delivery across administrative domains for these
  scenarios and document supporting functionality to enable this
  process.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc2784: Generic Routing Encapsulation (GRE) (Proposed Standard - Legacy stream)
    rfc3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6 (Proposed Standard - IETF stream)
    rfc7450: Automatic Multicast Tunneling (Proposed Standard - IETF stream)
    rfc4609: Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements (Informational - IETF stream)
    rfc4271: A Border Gateway Protocol 4 (BGP-4) (Draft Standard - IETF stream)
    rfc4604: Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast (Proposed Standard - IETF stream)
    rfc3376: Internet Group Management Protocol, Version 3 (Proposed Standard - IETF stream)



2017-08-09
10 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2017-08-09
10 Warren Kumari Last call was requested
2017-08-09
10 Warren Kumari Last call announcement was generated
2017-08-09
10 Warren Kumari Ballot approval text was generated
2017-08-09
10 Warren Kumari Ballot writeup was generated
2017-08-09
10 Warren Kumari IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2017-08-09
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-08-09
10 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-10.txt
2017-08-09
10 (System) New version approved
2017-08-09
10 (System) Request for posting confirmation emailed to previous authors: Robert Sayko , Ram Krishnan , Percy Tarapore , Toerless Eckert , Greg Shepherd
2017-08-09
10 Percy Tarapore Uploaded new revision
2017-08-09
09 Warren Kumari Doc has minor nits - a new version will help prevent later nitpicking...
2017-08-09
09 Warren Kumari IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-08-02
09 Warren Kumari IESG state changed to AD Evaluation from Publication Requested
2017-07-20
09 Cindy Morgan Responsible AD changed to Warren Kumari
2017-07-20
09 Cindy Morgan Intended Status changed to Best Current Practice
2017-07-20
09 Cindy Morgan IESG process started in state Publication Requested
2017-07-20
09 Cindy Morgan Working group state set to Submitted to IESG for Publication
2017-07-19
09 Cindy Morgan Notification list changed to Tim Chown <tim.chown@jisc.ac.uk>
2017-07-19
09 Cindy Morgan Document shepherd changed to Tim Chown
2017-07-19
09 Cindy Morgan Changed document writeup
2017-07-17
09 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-09.txt
2017-07-17
09 (System) New version approved
2017-07-17
09 (System) Request for posting confirmation emailed to previous authors: Robert Sayko , Ram Krishnan , Percy Tarapore , Toerless Eckert , Greg Shepherd
2017-07-17
09 Percy Tarapore Uploaded new revision
2017-02-02
08 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-08.txt
2017-02-02
08 (System) New version approved
2017-02-02
08 (System) Request for posting confirmation emailed to previous authors: "Ram Krishnan" , "Toerless Eckert" , "Greg Shepherd" , "Robert Sayko" , "Percy Tarapore" , mboned-chairs@ietf.org
2017-02-02
08 Percy Tarapore Uploaded new revision
2017-02-01
07 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-07.txt
2017-02-01
07 (System) New version approved
2017-02-01
07 (System) Request for posting confirmation emailed to previous authors: "Ram Krishnan" , "Toerless Eckert" , "Greg Shepherd" , "Robert Sayko" , "Percy Tarapore" , mboned-chairs@ietf.org
2017-02-01
07 Percy Tarapore Uploaded new revision
2016-11-15
06 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-06.txt
2016-11-15
06 (System) New version approved
2016-11-15
06 (System) Request for posting confirmation emailed to previous authors: "Ram Krishnan" , "Toerless Eckert" , "Greg Shepherd" , "Robert Sayko" , "Percy Tarapore" , mboned-chairs@ietf.org
2016-11-15
06 Percy Tarapore Uploaded new revision
2016-09-30
05 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-05.txt
2016-09-30
05 Percy Tarapore New version approved
2016-09-30
05 Percy Tarapore Request for posting confirmation emailed to previous authors: "Toerless Eckert" , "Ram (Ramki) Krishnan" , "Robert Sayko" , "Greg Shepherd" , mboned-chairs@ietf.org, "Percy Tarapore"
2016-09-30
05 (System) Uploaded new revision
2016-07-28
04 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-04.txt
2016-05-31
03 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-03.txt
2016-05-24
02 Greg Shepherd Just ended two weeks in state.
2016-05-24
02 Greg Shepherd IETF WG state changed to In WG Last Call from WG Document
2016-03-21
02 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-02.txt
2016-01-21
01 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-01.txt
2015-07-20
00 Percy Tarapore New version available: draft-ietf-mboned-interdomain-peering-bcp-00.txt