Hi Benson,
2014-12-03 19:38, Benson Schliesser:
Simple: I agree that it should be relatively straight-forward to fix
the namespace issue. While I'm not intimately familiar with it, I
think that RFC 3688 describes how the appropriate namespace can be
assigned. I'm comfortable describing this as editorial rather than
material.
RFC 3688 provides a way to ask IANA to assign a URN for a schema. It
doesn’t include guidelines on how that URN should look like. From the
point of view of the draft in question it is simple to modify the
examples to use TBD as a URN. However IANA would probably want
guidance as to what name to assign. Does it make sense to include a
suggestion in the IANA section ?
That makes sense to me. Maybe somebody else knows more about the
process, and could give better feedback, but what you propose is
exactly what I would do under the circumstances.
It was identified during shepherd review that a review of the XML
specifics of these specs was probably a good idea.
We'll take the action of getting in touch with whoever ends up being the
right person and identify the right solution for the namespace.
Probably very material: The draft really needs some kind of text
around the various issues I included in the "Second" issue
paragraph, in my previous message.
[Quote of this message:]
Second, the document doesn't seem to provide adequate operational
guidance on how to determine the route server JID, how to determine the
correct pubsub node values, etc. I assume that the server JID is a
configurable option. And I assume that the pubsub node is equivalent to
the 128 octet VPN ID. But neither seems to be spelled out clearly
(unless I'm overlooking it) and in any case there don't seem to be any
discussions of error handling. (In fact, the only comment I can find on
the 'node' value suggests vaguely that perhaps all values are implicitly
correct, in which case there needs to be some additional text about
troubleshooting.)
Specifically, there needs to be some text about assignment of
route-server JIDs. This should include some explanation about how
route-server JIDs relate to the redundancy scheme that's sketched
out in the draft. This should also include some kind of error
handling discussion around incorrect JIDs being used in messages,
etc. Much of the preceding also applies to pubsub 'node' values,
with an emphasis on the error handling issues. It is possible that
the authors have an editorial solution to this, which would avoid
material changes to the draft text, but my limited imagination can't
picture what that might look like.
The reference to the “jid” value in the RD assignment procedure is
incorrect; This procedure uses the IP identifier of the compute node.
Earlier versions of the document assume the JID to be the IP
identifier… this is no longer the case.
Thank you for highlighting this… I’ll update the document.
I look forward to seeing the updated text. I'm not sure that your
proposal covers all the issues that I've identified, but I'll wait to
see the text before I leap to any conclusions. :)
Let's try to avoid being dependant of how fast we can loop through
revision/feedback cycles, and anticipate resolutions.
What I think we need from you at this point, is (a) an exhaustive list
of the issues you see, with a level of detail appropriate so that we are
able to identify earlier in the process what changes are required to
satisfy your concerns, and (b) early feedback to Pedro suggested changes
(such as indication of issue that they would not address, if any).
For instance...
My guess is that Pedro's answer may address some of your concerns on the
jabber ids, but possibly not the ones related to route-servers (how they
are chosen and known to end-systems) and error handling. Is that correct
? On redundancy, can you provide more details on why you think is
missing and why you think the redundancy scheme relates to how
route-servers JIDs are chosen and known to end-systems ?
Best,
-Thomas
(as draft shepherd)
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
