Hi Stewart.
> At the time when I was getting this ready for the IESG, there was a strong
> view by the IESG that the IETF stream should not be used to publish
> this type of document, i.e. that this type of draft should go to the
> ISE. The view was that there were far too many AD sponsored drafts
FWIW, this document should be informational. I'm not sure why the
shepherd writeup went experimental. My recollection of the discussion
within the NVO3 WG was that Informational was the way to go. More
importantly, this document has all the hallmarks of a document that
has traditionally gone out as
Hi Joel.
> All of the proposed resolutions look very good. Thank you.
Great!
> With regard to routers and ARP caches, my concern is that from what I
> saw of the years, common practice did not seem to match the SHOULD from
> the RFCs. I am a little remote from most implementations at the mom
Hi Joel.
Thanks for the review comments. (And sorry for taking so long to respond!)
"Joel M. Halpern" writes:
> Major issues:
> The use of the term "switch" seems confusing. I had first assumed
> that it meant an ethernet switch (which might have abit of L3 smarts,
> or might not. I w
Hi Miguel.
Thanks for your comments.
Miguel Garcia <[EMAIL PROTECTED]> writes:
> Thomas, Harald:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> Please
"Soliman, Hesham" <[EMAIL PROTECTED]> writes:
> > I'll start with my protocol question:
> >
> > 7.2.7 Anycast neighbor announcements
> >
> > - "Second, the Override flag in Neighbor Advertisements SHOULD be
> > set to 0, so that when multiple advertisements are
> > receive
Scott W Brim <[EMAIL PROTECTED]> writes:
> I have one question on the protocol, and several on documentation.
> Since this is a significant protocol, documentation is very important.
> For the sake of new implementors I have a number of suggestions for
> clarity. Many of them have to do with the
