DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; 
 b=mrroyZZDWDYO9M3+kA8S0bUuBaZHKuPC7/Q3LI2GiluAVE5ic4XYc2VVA59ombwqKmZ/hkiTg9s8dbJD4wjYC39gZfI0KaCkDxxMG5l8XvRvLO9k3xXtxG1jzOcD+mdCn/yhPF+taa4aH9NUx0YoXSqs5mUtFRJpTS45P1MPWpA=;
 h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <CAHzoHbtNJ7HoQBvLqX3qt6YZXh+g=7_PfygxO504KpZ86uxddQ@mail.gmail.com>
Date: Tue, 14 Nov 2017 16:43:55 +0800
Cc: "mpls@ietf.org" <mpls@ietf.org>,
 "draft-ietf-mpls-ldp-mrt@ietf.org" <draft-ietf-mpls-ldp-mrt@ietf.org>, 
 The IESG <iesg@ietf.org>, Chris Bowers <cbowers@juniper.net>,
 "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1487156D-983D-4C06-96C5-80D24C426893@kuehlewind.net>
References: <150512983243.9691.9751851324237626342.idtracker@ietfa.amsl.com>
 <CY4PR05MB2823FF5CC38A3FD5C3DC6F3CA9500@CY4PR05MB2823.namprd05.prod.outlook.com>
 <5DD4B849-9894-4130-B458-4789C055BB35@kuehlewind.net>
 <CAHzoHbtNJ7HoQBvLqX3qt6YZXh+g=7_PfygxO504KpZ86uxddQ@mail.gmail.com>
To: Chris Bowers <chrisbowers.ietf@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/9PO9xBxGL128sKLy42qocr-mSVM>
Subject: Re: [mpls] 
 =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?=
 =?utf-8?q?ietf-mpls-ldp-mrt-06=3A_=28with_COMMENT=29?=
Precedence: list

That was just a comment. Just do the right thing=E2=80=A6

> Am 13.11.2017 um 17:59 schrieb Chris Bowers =
<chrisbowers.ietf@gmail.com>:
>=20
> Mirja,
>=20
> With respect to the second comment, since the behavior is defined in =
RFC5661, in this case I think it is better to not be more explicit in =
this document because it might confuse matters and be interpreted as =
specifying behavior that is in some way different from RFC5661. =20
>=20
> If it is OK with you, I will close out these two items without making =
changes to the current text.
>=20
> Thanks,
> Chris
>=20
> On Thu, Nov 9, 2017 at 3:28 PM, Mirja Kuehlewind (IETF) =
<ietf@kuehlewind.net> wrote:
> Hi Chris,
>=20
> see below.
>=20
> > Am 07.11.2017 um 01:14 schrieb Chris Bowers <cbowers@juniper.net>:
> >
> > Mirja,
> >
> > Thanks for the feedback.  Responses are inline with [CB].
> >
> > Thanks,
> > Chris
> >
> > -----Original Message-----
> > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Mirja =
K=C3=BChlewind
> > Sent: Monday, September 11, 2017 6:37 AM
> > To: The IESG <iesg@ietf.org>
> > Cc: mpls@ietf.org; draft-ietf-mpls-ldp-mrt@ietf.org; =
mpls-chairs@ietf.org
> > Subject: [mpls] Mirja K=C3=BChlewind's No Objection on =
draft-ietf-mpls-ldp-mrt-06: (with COMMENT)
> >
> > Mirja K=C3=BChlewind has entered the following ballot position for
> > draft-ietf-mpls-ldp-mrt-06: No Objection
> >
> > When responding, please keep the subject line intact and reply to =
all email addresses included in the To and CC lines. (Feel free to cut =
this introductory paragraph, however.)
> >
> >
> > Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-mrt/
> >
> >
> >
> > =
----------------------------------------------------------------------
> > COMMENT:
> > =
----------------------------------------------------------------------
> >
> > 1) I was just wondering if it was considered to just use one flag of =
the reserved field of the multi-topology extension in RFC7307 to =
advertise MRT support, given that MT must always advertised as well...?
> >
> > [CB]  I don't really understand the suggestion.  The document is =
requesting three values from the MPLS Multi-Topology Identifiers =
Registry (defined in RFC 7307). I think that we need all three, MRT-Red, =
MRT-Blue, and Rainbow MRT, for the protocol to work.  The registry has =
64k possible values (with 4k being most useful), of which only 6 are =
currently used.
>=20
> I was thinking just about the MRT Capability Advertisement (use a flag =
instead of a new TLV Type, namely TBD-MRT-LDP-1). However this is not =
important...
>=20
> >
> > Or are you referring to the request for a value from the Label =
Distribution Protocol (LDP) Parameters registry "TLV Type Name Space"?
> >
> > 2) Why would a node withdraw the MRT capability/ when would it send =
a MRT advertisement with S=3D0?
> >
> > [CB]  As an example, a configuration change on the node to no longer =
participate in label distribution for MRT would generally result in a =
withdrawal of the MRT capability, which is done by setting S=3D0.  The =
document currently has a  reference to RFC 5661 "LDP Capabilities" for =
more information on this.  Do you think more text is needed in the =
document to clarify this?
>=20
> Not necessarily. But it always helps to be rather explicit than =
implicit. It might be good to note that this is send based on things =
like config changes and not based on state changes that are happening =
during usual operation. However, maybe this is more obvious to people =
who are more expert than I am.
>=20
> Mirja
>=20
> >
> > 3) If you update the document, please also see the gen-art review: =
there are many small nits which will probably also be caught by the RFC =
editor but if you can fix them now, that's even better!
> >
> > [CB]  Thanks.  I did that in a separate response.
> >
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
>=20
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>=20