> Major issues: None
Thanks for your review Jouni.
> Minor issues:
> 1) Section 7 Security Considerations is a bit thin.. aren't there anything a
> rogue host could do?
Well, a rogue host can only register name mappings if it has the authentication
keys for a given map-server. So its not the na
Okay. I will keep the last paragraph only. Thanks.
Dino
> On Feb 5, 2019, at 7:59 PM, Benjamin Kaduk wrote:
>
> On Tue, Feb 05, 2019 at 07:56:39PM -0800, Dino Farinacci wrote:
>>> Nits/editorial comments: Section 2: Get rid of everything except the last
>>> paragr
> Nits/editorial comments: Section 2: Get rid of everything except the last
> paragraph.
Are you sure? I just followed what RFC 8174 suggested. Give me reason to not
follow it?
Dino
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailma
; https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc8113bis-02
>
> Cheers,
> Med
>
>> -Message d'origine-
>> De : mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
>> Envoyé : vendredi 21 décembre 2018 07:57
>> À : Dino Fa
Thanks all.
Dino
> On Dec 20, 2018, at 10:57 PM,
> wrote:
>
> Re-,
>
> Seems we are all in agreement.
>
> I implemented the changes to 8113bis in my local copy.
>
> Thank you, Brian.
>
> Cheers,
> Med
>
>> -----Message d&#x
> On 2018-12-21 09:18, Dino Farinacci wrote:
>> Brian wants to drop the reference to 6833bis from 8113bis. I am fine with
>> that. That reference being at the top of the draft saying “Updates 6833bis”.
>> If we remove that, he may concur. Please confirm Brian (again).
stry into 6830bis, which is where they naturally belong. If you
>> don't want to do that, I think you have to leave them in 8113bis and
>> simply lose the citation of 6833bis, which serves no purpose that
>> I can see.
>> Regards
>>Brian
>> On 2018-12-21 0
:
>
> Values in the "Not Assigned" range can be assigned via Standards
> Action [RFC8113].
>
> Cheers,
> Med
>
>> -Message d'origine-
>> De : Dino Farinacci [mailto:farina...@gmail.com]
>> Envoyé : mercredi 19 décembre 2018 19:00
ular, the
> exhaustion of the LISP Packet types.
>
> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the
> "updates" header because (2) can be also seen as an extension.
>
> Cheers,
> Med
>
>> -Message d'origine
> IMHO we just drop the “update 6833bis” and we are fine.
I agree.
Dino
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Mohmad to comment.
Dino
> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern wrote:
>
> That is the other fix he offered. Just remove the updates tag.
> I will leav eit to you and the the authors to determine which is correct.
> Yours,
> Joel
>
> On 12/18/18 11:43
8113bis should say that is it *extending* the type field so we can have more
types. The word “update” I always had a problem with because it can be
interpreted as “replacing". Replacing something to fix a problem.
8113 is simply asking for one of the type value codepoint, so there can be
anoth
Thanks again Pete for all your effort.
Dino
> On Sep 19, 2018, at 2:07 PM, Pete Resnick wrote:
>
> Reviewer: Pete Resnick
> Review result: 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
> Reviewer: Pete Resnick
> Review result: Ready with Nits
>
> 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 commen
There is no other text in the email. So can’t be sure what you are saying. I’m
guessing you are fine with the proposed text?
My co-authors have to agree though. ;-)
Dino
> On Dec 1, 2016, at 11:55 AM, Jari Arkko wrote:
>
> That would work for me.
>
> Jari
>
___
tion for unicast head-end replication and identifies the
receiver ETR that needs to be notified should the root ITR of the
distribution tree move to another site. The root ITR can change when the
source EID is roaming to another LISP site.
Dino
>
> -Original Message
> Could you make this sentence more readable?
>
> It determines the downstream destination for unicast head-end replication
> and identifies the
> receiver ETR that needs to be notified should the root of the
> distribution tree move to another site.
>
> "should be", "moving”?
I do not u
> Lucy,
>
> Many thanks for your review.
>
> Dino, Stig, does this discussion lead you to consider adding some
> clarifications to the document? I am not going to require those (just posted
> a no-obj for the document on today’s telechat), but wanted to give you an
> opportunity to consider th
> Two. One at all LISP sites (not one per LISP site) and part of the overlay
> and possibly one in the underlay.
> [Lucy] Thank, Dino. This is helpful. So the attributes proposed in this draft
> is used in the first PIM instance, right? These attributes are only used by
> ETRs to send join/prune
>> the draft assumes that PIM works within individual LISP sites but PIM
>> mcast transport may not be supported among LISP sites. However the
>> mechanism itself does not enforce a unique (unicast or mcast) underlay
>> transport among LISP sites. Could some ETRs request unicast transport,
>> o
> the draft assumes that PIM works within individual LISP sites but PIM mcast
> transport may not be supported among LISP sites. However the mechanism itself
> does not enforce a unique (unicast or mcast) underlay transport among LISP
> sites. Could some ETRs request unicast transport, other req
> On the basis that each RTR RLOC can be from a different address family,
> than I would say that the number of RTRs cannot be determined from the LCAF
> Length field. The length alone would not tell you the breakdown of RTR RLOCs
> between the address families, so the only way to tell ho
> Summary: This draft is ready for publication as an Experimental RFC
Thanks for your review Pete. Brian and I appreciate it.
> Though this is not an area of expertise for me, the document is clearly
> written, I reviewed the data structures and they appear correct, and the
> document seems rea
Manish, we wanted a more integrated solution. Many products can’t do
encapsulation and encryption at one time in one router. There are 2-box
solutions are there. Plus, there are more RTT packet exchanges for IPsec which
would cause more packet loss when the ITR would have to resolve an EID to an
Thanks for your second round of comments Peter. See comments inline.
> Page 6, Rsvd2 definition: the definition both says "reserved for future use"
> and then says some types actually use it. That sounds like present use.
> And to generically say that it should be sent as zero and ignored, but th
Kathleen, thanks for the comments. I have made changes to reflect all your
editorial comments. I will be posting a draft-ietf-lisp-multicast-09.txt with
yours and Ralph's comments.
Dino
On Oct 3, 2011, at 8:23 PM,
wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
26 matches
Mail list logo
