Good discussions. Here are some of my comments. On Sun, Mar 3, 2013 at 12:50 AM, Richard Alimi <[email protected]> wrote:
> Thank you very much Enrico for helping to target the discussions. > > My opinions on the outstanding issues that you mentioned below: > > On Fri, Mar 1, 2013 at 7:12 AM, Enrico Marocco < > [email protected]> wrote: > >> Hi all, >> > ... > >> - get acquainted with the issues that have been discussed since the >> previous meeting, including (in no particular order): >> o reason phrase for error messages; >> > > I'd prefer to leave it out, but I don't feel strongly. Ted Hardie proposed > to remove it in his review of the draft, citing that free-form strings > typically introduce more complexity due to internationalization. If it is > added back, I would propose that it be a US-ASCII string, just like the > other strings already in the protocol. > I would also support that we leave out free-form strings for error messages. > > o relative vs. absolute URIs; >> > > I believe that allowing relative URIs is a good thing. Speaking from some > experience, it actually would have simplified my implementation. > I also think allowing relative URIs is good, as the current spec stated, per Section 5 of RFC3986. > > >> o behavior of degenerated map filtering; >> > > I support returning the whole map when the list of sources and > destinations are empty. > Thinking the issue a bit, I am somehow leaning towards returning empty instead of full map. Consider the Network Location Map filter. Suppose the filter specifies a set S of PIDs. The semantics (code) appears to be foreach p in S return network map of p Now, if S is empty, the for loop does not execute and the result should be empty. If we allow *, then it will return all, but we are discussing empty. Similarly for Network Cost Map filtering. Given source set S and destination set D, the code appears to me to be: foreach s in S for each d in D return cost from s to d Hence, when S or D is empty, the program returns null. This appears to be simple, consistent. Does this make sense? > > >> o merge of cost-mode and cost-type in a single type; >> > > I'd prefer to keep them separate. I believe that the proposals for merging > them will make the registry very messy and cumbersome when new cost types > are registered. > > There has been discussion over whether cost mode is useful. I believe it > is for the following reasons: > (1) There are good use cases for numerical costs (e.g., P4P). > (2) There are good use cases for ordinal costs (e.g., the proxidor > approach). > (3) Removing support for either numerical or ordinal costs means that we > are going to revisit one of the discussions from very early on in the > working group, where people worked together quite well to merge 3 drafts > into a single alto protocol. > (4) It should be up to the server as to whether it supports numerical or > ordinal costs, and a client needs to be able to tell which it is receiving > > Cost Mode is currently the way we communicate how the client should treat > the costs it has received from the server. > > I am also OK with keeping Mode for now. > o format of endpoint properties; >> > > The current draft allows them to be generic json values (not only > strings), though the base protocol only requires clients to understand > strings. > One possibility to address this discussion is to demonstrate generic json value for endpoint property up front. For example, we demonstrate the pid endpoint property as an object: {"value" : "PID1", "map-vtag": "1266506139"} for the current example (Sec. 9.3.1.6): { "meta" : {}, "data": { "map-vtag" : "1266506139", "map" : { "ipv4:192.0.2.34" : { "pid": "PID1", "example-prop": "1" }, "ipv4:203.0.113.129" : { "pid": "PID3" } } } } How does this sound? If there is agreement, we can do a quick update of the spec and circulate on the mailing list to move on quickly. Richard This is exactly how we treat cost values today, and I don't see a reason > for it to be different. > > Extensions can define property and cost values that have other formats, > such as arrays, objects, etc. > > >> o mandatory vs. optional services; >> > > I don't think there has been much debate over what is mandatory and what > is optional, right? Can you point me to this discussion? > > >> >> - review the latest version of the protocol, with special attention on >> the above-mentioned issues; >> >> - share your opinion on the list. Please note that this is essential >> for us to determine consensus, so, regarding the open issue >> resolution options, even a motivated "don't care" is useful feedback. >> >> We'd like to ask the editors of the protocol draft to circulate an >> update on the changes of the latest version, creating a good starting >> point for discussion. >> >> If we will be able to determine consensus for moving the document >> forward before the face-to-face meeting (that this time comes very late >> in the week, and longer than requested), we will be happy to bash the >> agenda on the list and possibly allocate extra time for unchartered >> topics that at this time don't have a slot. >> >> Comments are welcome. >> >> Enrico >> >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> >> > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
