Hi Roni and Alissa,
Thanks both for the review. We have addressed the comments from you both in
the latest version (11) but have not posted as it was so close to the IESG
telechat. A few comments (DK>>) below on the specific comments:
Re: Minor issues:
> 1. In section 1.1 last bullet does it mean that you MUST NOT use H-PCEP on
the
> internet?
DK>> The draft (section 1.1) now includes the following text.
>>
The hierarchical relationship model is described in [RFC6805].
It is applicable to environments with small groups of domains
where visibility from the ingress LSRs is limited. As highlighted
in [RFC7399] applying the hierarchical PCE model to very large
groups of domains, such as the Internet, is not considered
feasible or desirable.
<<
> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE
sends an
> open with P flag =0 can the response open be sent with a P flag =1 and if
yes
> what should be the action of the originator. I did not see any text about
this
> case.
DK>> According to RFC 5440, the Open message is not a request response
exchange. Both entities send an Open message, and indeed they may even
overlap. In our H-PCE extensions the P flag indicates that the sender wants
the receiver to act as its parent. In the example we give, it should be fine
for one party to not set the P flag in the first Open message seen on the
wire, and for the second part to set the P flag in the second Open message
seen on the wire. Therefore, I don't think this needs to be address as an
implementor should be familiar with the Open message behavior.
> Nits/editorial comments:
> 1. in section 1 "achild" should be " a child"
DK>> Fixed, thanks!
> 2. Section 2.4 repeat some of the text from RFC6805 1.3.2.2 but using
> different sentence structure. Is there a reason to change the wording.
DK>> In the new version of our I-D (v11) we have three paragraphs for this
section, the first includes text from RFC6805 and uses quotes the reference
text, but we also include some additional discussion (in two further
paragraphs) text not used in 6805 to further define domain diversity.
DK>> Again, thank you for the reviews. Its very much appreciated. We have a
new version ready which also addresses the above, and comments from Kyle
(secdir) and Mike (rtgdir).
BR, Dan and the other authors.
-----Original Message-----
From: Pce <pce-bounces@xxxxxxxx> On Behalf Of Alissa Cooper
Sent: 13 May 2019 18:23
To: Roni Even <ron.even.tlv@xxxxxxxxx>
Cc: gen-art@xxxxxxxx; draft-ietf-pce-hierarchy-extensions.all@xxxxxxxx;
pce@xxxxxxxx; ietf@xxxxxxxx
Subject: Re: [Pce] [Gen-art] Genart last call review of
draft-ietf-pce-hierarchy-extensions-10
Roni, thanks for your review. I raised your point about the missing OPEN
(error) case in my DISCUSS ballot. One comment below.
> On Apr 14, 2019, at 6:42 AM, Roni Even via Datatracker <noreply@xxxxxxxx>
wrote:
>
> Reviewer: Roni Even
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-pce-hierarchy-extensions-??
> Reviewer: Roni Even
> Review Date: 2019-04-14
> IETF LC End Date: 2019-04-15
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
> The document is almost ready for publication as a standard track RFC.
>
> Major issues:
>
> Minor issues:
> 1. In section 1.1 last bullet does it mean that you MUST NOT use H-PCEP on
the
> internet?
This text is the same as what appears in RFC 7399 and I think it captures
the intent clearly enough (although happy to see the authors answer your
question).
Thanks,
Alissa
>
> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE
sends an
> open with P flag =0 can the response open be sent with a P flag =1 and if
yes
> what should be the action of the originator. I did not see any text about
this
> case.
>
> Nits/editorial comments:
> 1. in section 1 "achild" should be " a child"
> 2. Section 2.4 repeat some of the text from RFC6805 1.3.2.2 but using
> different sentence structure. Is there a reason to change the wording.
>
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Pce mailing list
Pce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/pce
